System and method for securing information in electronic exchange transactions

ABSTRACT

A method and system for processing electronic offers comprising at least one processing device that submits an electronic offer for a first policy, receives a bid that is responsive to the offer and an acceptance of the bid, and executes a transaction workflow including an agreement with a buyer associated with the bid. In the agreement, the buyer receives the first policy and pays premiums to the first entity that keep the first policy in force, pays certain fees to a second entity, which second entity issues to the owner at least one second policy with a second benefit value based on the life of the insured, the second benefit value comprising a portion of the first benefit value, and pays or causes to be paid to the second entity at least a second benefit value based on the life of the insured.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material,which is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND OF THE INVENTION Field of the Invention

This application generally relates to performing secure exchangetransactions involving life insurance policies, and in particular,systems and methods for electronically managing identifying informationof electronic exchange transactions.

Description of the Related Art

Due to various reasons such as retirement, health, changes in estatevalue, estate taxes or premium costs, the owner of a life insurancepolicy may decide to (i) surrender the policy to the carrier of thepolicy and receive the cash surrender value (if any) under the policy;(ii) sell the policy to a life settlement company for an amount inexcess of the cash surrender value; or (iii) sell the policy to a lifesettlement company in exchange for the life settlement company's promiseto (A) pay the premiums required to keep the policy in force and (B)designate the owner or the owner's beneficiary as an irrevocablebeneficiary for a portion of the policy's death benefit.

Commonly assigned U.S. Pat. No. 8,108,308 describes a method forstructuring a life settlement with a paid up policy transaction. In themethod, a policy holder sells or otherwise exchanges their existinginsurance policy on a secondary market. In exchange for selling theinsurance policy to a buyer, the buyer purchases a second, paid-upinsurance policy in the name of the policy holder as beneficiary andwith a death benefit less than the death benefit of the policy holder'spolicy. The buyer becomes the beneficiary of the first policy. Thismethod represented an improvement over existing life settlement options.

There remains a need in the art for further improvements to lifesettlement options to increase the benefits to the parties involved.

SUMMARY OF THE INVENTION

The present invention provides a method and system for conductingtransactions through an electronic interface. The system comprises atleast one processing device and at least one computer readable storagedevice storing data instructions that, when executed by the at least oneprocessing device, cause the at least one processing device to submit anelectronic offer for a first policy that is assigned from an owner ofthe first policy. The first policy includes a first benefit value on alife of an insured and is issued by a first entity. The offer comprisesdata including an offer price for the first policy and details regardingthe first policy. The processing device is caused to receive a bid thatis responsive to the offer and an acceptance of the bid based on asignal from a client device via an application interface. The at leastone processing device is further caused to execute a transactionworkflow including generating an agreement with a buyer associated withthe accepted bid. In the agreement, the buyer receives the first policyand pays premiums to the first entity that keep the first policy inforce, pays certain fees to a second entity, which second entity issuesto the owner at least one second policy with a second benefit valuebased on the life of the insured, the second benefit value comprising aportion of the first benefit value, and pays or causes to be paid to thesecond entity at least a second benefit value based on the life of theinsured.

The assignment may be based on a transaction executed by the owner ofthe first policy with the second entity. In one embodiment, theprocessing device may be configured to electronically receive theassignment via data entry or file attachment from a computing deviceassociated with the owner of the first policy. The processing device maybe further configured to issue the second policy as a paid-upcertificate of insurance under a group master policy. In anotherembodiment, the processing device may be further configured to issue thesecond policy as an individual paid-up life insurance policy.

The processing device may issue the second policy to the owner whereinthe second policy includes a beneficiary that is chosen by the owner.The processing device may also issue the second policy to the ownerwherein the owner is not required to pay premiums to keep the secondpolicy in force. The processing device may be further configured toissue the second policy to the owner wherein the first entity pays thefirst benefit value on the life of the insured to the buyer, the buyerpays or causes to be paid at least the second benefit value on the lifeof the insured to the second entity, and the second entity pays thesecond benefit value on the life of the insured to the beneficiary ofthe second policy.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated in the figures of the accompanying drawingswhich are meant to be exemplary and not limiting, in which likereferences are intended to refer to like or corresponding parts.

FIG. 1 illustrates a computing system according to an embodiment of thepresent invention.

FIG. 2 illustrates a settlement exchange server according to anembodiment of the present invention.

FIG. 3 illustrates a computing system according to another embodiment ofthe present invention.

FIG. 4 illustrates a flowchart of a life settlement transactionaccording to an embodiment of the present invention.

FIG. 5 illustrates a flowchart of a method for conducting a privatizedtransaction on an electronic exchange according to an embodiment of thepresent invention.

FIG. 6 illustrates a flowchart of a method for performing policyexchange analysis according to an embodiment of the present invention.

FIG. 7 presents a flowchart of a method for creating a database of keyindicators for each investor according to an embodiment of the presentinvention.

FIG. 8 presents a flowchart of a method for determining risk appetite ofinvestors according to an embodiment of the present invention.

FIG. 9 presents a flowchart of a method for determining likely investorsof a policy exchange program according to an embodiment of the presentinvention.

FIG. 10 presents a flowchart of a method for engaging life insurancecarrier to issue certificates for a policy exchange program according toan embodiment of the present invention.

FIG. 11 presents a flowchart of a method for obtaining information ofpolicy assets eligible for policy exchange according to an embodiment ofthe present invention.

FIG. 12 presents a flowchart of a method for determining a range ofpremium payment cash flows according to an embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

Subject matter will now be described more fully hereinafter withreference to the accompanying drawings, which form a part hereof, andwhich show, by way of illustration, exemplary embodiments in which theinvention may be practiced. Subject matter may, however, be embodied ina variety of different forms and, therefore, covered or claimed subjectmatter is intended to be construed as not being limited to any exampleembodiments set forth herein; example embodiments are provided merely tobe illustrative. It is to be understood that other embodiments may beutilized and structural changes may be made without departing from thescope of the present invention. Likewise, a reasonably broad scope forclaimed or covered subject matter is intended. Throughout thespecification and claims, terms may have nuanced meanings suggested orimplied in context beyond an explicitly stated meaning. Likewise, thephrase “in one embodiment” as used herein does not necessarily refer tothe same embodiment and the phrase “in another embodiment” as usedherein does not necessarily refer to a different embodiment. It isintended, for example, that claimed subject matter include combinationsof exemplary embodiments in whole or in part. Among other things, forexample, subject matter may be embodied as methods, devices, components,or systems. Accordingly, embodiments may, for example, take the form ofhardware, software, firmware or any combination thereof (other thansoftware per se). The following detailed description is, therefore, notintended to be taken in a limiting sense.

FIG. 1 presents a computing system according to an embodiment of thepresent invention. A computing system 100 may include a client device102 that can communicate with second server 106 to conduct a lifeinsurance policy transaction through network 108. The life insurancepolicy transactions may include an assignment of a policy (issued froman entity associated with first server 104) to an entity associated withsecond server 106. The second server 106 may then subsequently uploadthe assigned policy on settlement exchange server(s) 110 either via adirect network connection or network 108. Alternatively, the clientdevice 102 may conduct the life insurance policy transaction with thesecond server 106 and assign the policy to the second server 106 on thesettlement exchange server(s) 110. Uploading the assigned policy mayinclude the settlement exchange server(s) 110 generating an assignmententry that may include recording assignment documentation, policydetails (e.g., benefits or face value), policy issuer information, andowner information. Assignment of the policy to the second server 106 mayallow the second server 106 to list and sell the policy through thesettlement exchange server(s) 110.

The settlement exchange server(s) 110 may comprise computing hardwarethat enable a party to submit a bid to buy one or more issued policies(e.g., client device 112), or an offer to sell one or more issuedpolicies (e.g., second server 106, client device 114, or client device114 on behalf of second server 106), through an application interface toan electronic exchange network or marketplace via network 108. It isnoted that any one of servers and client devices may be used by partiesto submit bids and offers through settlement exchange server(s) 110.Bids or offers may be communicated to a processor at settlement exchangeserver(s) 110, where the bid or offer can be stored in a bid-offerqueue. Bids and offers may be sorted based upon time of submission,price, or any other suitable criterion. Bids or offers may be presentedto an intended party and once displayed, the bid or offer may beaccepted. Bids and offers may include portions indicating a descriptionof an underlying policy, a bid price, and an offer price.

Servers, as described herein, may comprise at least a special-purposedigital computing device including at least one or more centralprocessing units and memory. A server may also include one or more ofmass storage devices, power supplies, wired or wireless networkinterfaces, input/output interfaces, and operating systems, such asWindows Server, Mac OS X, Unix, Linux, FreeBSD, or the like. In anexample embodiment, a server may include or have access to memory orcomputer readable storage devices for storing instructions orapplications for the performance of various functions and acorresponding processor for executing stored instructions orapplications. For example, the memory may store an instance of theserver configured to operate in accordance with the disclosedembodiments.

Client devices 102, 112, and 114 may comprise computing devices (e.g.,desktop computers, terminals, laptops, personal digital assistants(PDA), cellular phones, smartphones, tablet computers, or any computingdevice having a central processing unit and memory unit capable ofconnecting to a network). Client devices may also comprise a graphicaluser interface (GUI) or a browser application provided on a display(e.g., monitor screen, LCD or LED display, projector, etc.). A clientdevice may also include or execute an application to communicatecontent, such as, for example, textual content, multimedia content, orthe like. A client device may also include or execute an application toperform a variety of possible tasks, such as browsing, searching,communicating. Client devices may include or execute a variety ofoperating systems, including a personal computer operating system, suchas a Windows, Mac OS or Linux, or a mobile operating system, such asiOS, Android, or Windows Phone, or the like. A client device may includeor may execute a variety of possible applications, such as a clientsoftware application enabling communication with other devices, such ascommunicating one or more messages, such as via email, short messageservice (SMS), or multimedia message service (MMS).

Network 108 may be any suitable type of network allowing transport ofdata communications across thereof. The network 108 may couple devicesso that communications may be exchanged, such as between servers andclient devices or other types of devices, including between wirelessdevices coupled via a wireless network, for example. A network may alsoinclude mass storage, such as network attached storage (NAS), a storagearea network (SAN), cloud computing and storage, or other forms ofcomputer or machine-readable media, for example. In one embodiment, thenetwork may be the Internet, following known Internet protocols for datacommunication, or any other communication network, e.g., any local areanetwork (LAN) or wide area network (WAN) connection, cellular network,wire-line type connections, wireless type connections, or anycombination thereof. Communications and content stored and/ortransmitted to and from client devices and servers may be encryptedusing, for example, the Advanced Encryption Standard (AES) with a 128,192, or 256-bit key size, or any other encryption standard known in theart.

FIG. 2 illustrates a settlement exchange server according to anembodiment of the present invention. Settlement exchange server(s) 110may include listing module 202, database 204, transaction processor 206,web server 208, and communication interface 210. Client devices andservers of parties may communicate with settlement exchange server(s)110 by connecting with web server 208 through communication interface210. Web server 208 may service requests from the client devices andservers over a network communication. Web server 208 may access datastored in database 204. Database 204 may store user profiles of partiesincluding contact information, certifications (e.g., licensinginformation). The database 204 may be implemented with a group ofnetworked server computers or other storage devices. The web server 208may authenticate client devices and servers based on information storedin database 204.

Transaction processor 206 may be in communication with an interface usedto submit and respond to bids and offers in accordance with the presentinvention. Bids and offers may be processed by transaction processor 206and stored to database 204. Bids and offers may include a description ofan underlying issued policy, a bid price, or an offer price.Additionally, offers may include documentation, such as proof of policy.Listing module 202 may be accessed through web server 208 to generate alisting of bids and/or offers based on bids and offers retrieved fromdatabase 204. The listing of bids and/or offers may be presented to apool of parties or to a specific party and sorted based upon time ofsubmission, price, or any other suitable criterion.

The bids and/or offers may be selected for entering proposals totransaction processor 206. Transaction processor 206 may be programmedwith computer-executable instructions to receive requests, execute therequests, and read/write to database 204 based on the requests. Thetransaction processor 206 may further execute exchange market functions,such as pairing of bids and offers between parties based on enteredproposals. Bids or offers may be presented to intended parties by webserver 208 and communication interface 210, and once displayed, may beaccepted or declined.

FIG. 3 illustrates a computing system according to another embodiment ofthe present invention. A computing system 300 may include settlementexchange server(s) 310 in communication with servers 302, 304, 306 andclient devices 312, 314, 316 through network 308. The settlementexchange server(s) 310 may enable the servers 302, 304, 306 and clientdevices 312, 314, 316 to interact with each other and enact transactionsthrough an exchange of bids and offers. Listing module 320 may makelistings available by allowing to the servers 302, 304, 306 and clientdevices 312, 314, 316 to post or respond to bids and offers. Bids andoffers may be processed and stored to database 328 by processor 324. Thelisting module 320 may retrieve the bids and offers from database 328 togenerate listings for browsing and selection. For example, any one ofclient devices 312, 314, 316 may browse an interface including listingoffers from sellers of issued policies and identify one or more offersto bid on. The settlement exchange server(s) 310 may then transmit bidson offers via the network 308 to parties who submitted the offers andupdate database 328. A party receiving a bid may be presented with thebid via message communication or on a listing interface.

Identity manager 326 may provide identity services that control thedissemination and access of identifying information of parties. Incertain embodiments, bids and offers may include identifying informationof insureds of policies, bidding and offering parties, or counterpartiesacting as brokers. A party participating on settlement exchangeserver(s) 310 may desire not to have such identifying information forbids and offers displayed. This may be because the circumstances ofselling an issued policy may be a private matter that is desired to bekept confidential by the insureds, or that parties may be concerned thatthey will not receive a fair price. In such instances, identity manager326 may be configured to block identifying information from beingdisplayed at least until a certain transaction or agreement hasoccurred. For example, before accepting an offer, identity manager 326may provide procedures in place to protect the confidentiality ofinsureds which may be dependent on state regulations governing thehandling of confidential information. Identity manager 326 may prompt abidding party to identify parties or potential parties associated withthe bid and whether the end buyers will have access to personalinformation of the policy insured. As such, the insureds personalinformation may be protected from public dissemination.

Accepting a bid to an offer may result in an agreement andsales/purchasing/exchange transaction that may be facilitated byprocessor 324. For example, processor 324 may generate forms orcontracts and notify relevant parties of a sale of one or more issuedpolicies agreed upon. Agreements and transactions may be recorded byprocessor 324 as a transactional history, which may be analyzed and/oraggregated for various purposes by analysis module 322. Analysis module322 may evaluate and compare policies to determine or calculate certainbenchmarks. The evaluation and comparison may include statistical andhistorical comparison, inputting of variables into a model simulation,predictive analysis, etc. Analytics data is generated by the analysismodule 322 and may be presented in a dynamic, multi-dimensional formatwhich allows for the speedy presentation of information.

The disclosed computer systems and computerized methods may be used tofacilitate transactions, such as policy owners selling their existinglife insurance policies on a secondary market. Selling life insurancepolicies on a secondary market are further described in commonly ownedU.S. Pat. No. 8,108,308, entitled “LIFE SETTLEMENT TRANSACTION SYSTEMAND METHOD INVOLVING APPORTIONED DEATH BENEFIT” which is hereinincorporated by reference in its entirety. The present applicationdiscloses improved systems and methods that provide a variety offeatures in a settlement exchange system to facilitate a secondarymarket for policies. Policies may include agreements, contracts,options, terms, or conditions that provide protection, insurance, orhedging, for example. The systems and methods may provide settlementexchange servers which present policy information to parties on adisplay screen and enable those parties to respond to the policyinformation. According to one embodiment, a database containinginformation relating to parties in the exchange system may indicatewhich participants are buyers or sellers, and what, if any, limitationsare placed on the activity of the participants. In another embodiment,anonymous trading features may prevent third-parties from knowing theidentity associated with an offer and may permit configuration ofanonymous identity parameters.

The disclosed systems and methods may also evaluate the fair value of,for example, an existing life insurance policy where the considerationis a future contingent payment payable upon the death of the insuredunder the life insurance policy asset. An appetite may be determined ofinvestors for the life insurance policy asset and their ability toaccept a risk and return profile which may differ from the purchase oflife insurance policy in which the consideration is paid in cash at theclosing of the transaction. The characteristics and risk profile(including expected return and volatility) of each potential transactionmay be determined using database parameters. The fit of these resultsmay then be filtered through an eligibility criteria and risk profile ofeach potential investor to determine an expected return on investment tobe generated based on cashflows and a sponsor's expected profit to begenerated by each transaction. The filtering may then provide boundariesfor potential combination of cash and death benefit that can be offeredto a seller of a life insurance policy.

FIG. 4 presents a flowchart of a life settlement transaction accordingto one embodiment of the present invention. A transaction 400 mayinclude a policy owner 404 that may first purchase a life insurance(“Policy 1”) from a first insurance company 402 on the life of anindividual at step 410. The Policy 1 may include a designatedbeneficiary of the owner's choosing and a certain face value, forexample $1,000,000, to be received by the policy's beneficiary as adeath benefit (“Benefits 1”) upon the death of the individual insuredunder the policy. The beneficiary may be the policy owner 404 or theindividual whose life is insured by the policy, or another persondesignated by the policy owner 404. The person whose life is insured(“Insured 1”) may be the policy owner 404 or another person for whom thepolicy owner 404 has an insurable interest.

Subsequently, in step 412, the policy owner 404 reaches an agreementwith a second insurance company 406, and the policy owner 404 assignsPolicy 1 to the second insurance company 406. In exchange for thisassignment, the second insurance company 406 at step 414 may issue asecond life insurance policy (“Policy 2”) with a death benefit(“Benefits 2”) to the policy owner 404. The second insurance company 406may include a server that can calculate appropriate levels of insuranceto purchase in exchange for Policy 1 and the actuarial factors relevantto both Policy 1 and Policy 2. For example, Policy 2 may comprise a$300,000 paid-up certificate of insurance under a group master policy.No premiums may need to be paid by policy owner 404 to keep thecertificate in force. Insured 1 is the insured under the certificate ofinsurance, and the policy owner 404 can choose the beneficiary.Alternatively, Policy 2 may comprise an individual paid-up lifeinsurance policy to policy owner 404. The market value of Policy 1 mayserve as the initial premium payment under the Policy 2 insurancecoverage.

The second insurance company 406 may then sell Policy 1 to a Buyer 408,at step 416, in exchange for an agreement 418 by the Buyer 408 to (i)pay the premiums required to keep the Policy 1 in force (422), (ii) paycertain fees to the second insurance company 406, and (iii) pay or causeto be paid an amount of Benefits 2 (e.g., $300,000) to the secondinsurance company 406 when Insured 1 dies. When Insured 1 dies, (a) thefirst insurance company 402 will pay the Benefits 1 to Buyer 408, theowner of Policy 1, (b) Buyer 408 will pay the amount of Benefits 2 tothe second insurance company 406, and (c) the second insurance company406 will pay the amount of Benefits 2 to the beneficiary under Policy 2.As an alternative to steps (a) and (b) above, the first insurancecompany 402 could pay $700,000 (i.e., the difference between the amountof Benefits 1 and Benefits 2) to Buyer 408 and $300,000 (i.e., theamount of Benefits 2) directly to the second insurance company 406.

According to another embodiment, to the extent that policy owner 404wants to receive cash compensation at closing in addition to a paid-uplife insurance policy/certificate, the second insurance company 406 canaccommodate that by (i) structuring Policy 2 to have some cash value,(ii) making a cash payment to policy owner 404, or (iii) providingpolicy owner 404 with an annuity. For example, instead of providingpolicy owner 404 with a $300,000 paid-up certificate of insurance, thesecond insurance company 406 could give policy owner 404 (i) a $200,000paid-up certificate and (ii) $40,000 of cash or cash equivalent. Thecash may be funded by the sale of the Policy 1 in step 416 where thesecond insurance company 406 sells Policy 1 to buyer 408 in exchange foran agreement by the buyer 408 to (i) pay the premiums required to keepPolicy 1 in force, (ii) pay certain fees to the second insurance company406, (iii) pay $40,000 to the second insurance company 406 at the timeof closing, and (iv) pay or cause to be paid $250,000 to the secondinsurance company 406 when Insured 1 dies.

FIG. 5 presents a flowchart of a method for conducting a privatizedtransaction on an electronic exchange according to an embodiment of thepresent invention. Assignment of a first policy is received by a serverfrom an original owner of the first policy, step 502. The first policymay be an insurance policy including a given value on a life of aninsured that is issued to the original owner (which may or may not bethe insured) by a first insurance company. A transaction may be executedby the original owner of the first policy that causes the assignment,such as a transfer of the first policy to a second insurance company,reinsurer, or any other entity for a given sum of money. The firstpolicy may be designated by the assignment to an assignee or receivingparty that may be the second insurance company, reinsurer, etc. Theassignment may be received electronically by a recording system of theserver via data entry and/or file attachments a computing deviceassociated with the original owner.

At least one second policy is issued by the server to the originalowner, step 504. The second policy may include a paid-up certificate ofinsurance under a group master policy or an individual paid-up lifeinsurance policy with a value selected or determined by the server thatis a portion of the value of the first policy. Issuance of the secondpolicy may supplement the transaction. The insured under the firstpolicy may be the insured under the second policy and the original ownermay choose a beneficiary. Additionally, the original owner may not berequired to pay premiums to keep the second policy in force. In effect,the intrinsic value of the first policy from the transaction may serveas the initial premium payment under the second policy.

The server submits a confidential offer including the first policy to anexchange server via an application interface, step 506. The server maybe registered with the exchange server as a party authorized to postoffers as well as bids to an electronic exchange or marketplace.Submitting the confidential offer may include an entry of data includingan offer price for the first policy, details regarding the first policy,parameters of confidentiality, a recipient of the offer (if specified),and any other information associated with the offer to a transactionprocessor by the exchange server. The transaction processor may recordthe confidential offer and perform market exchange functions thatdisseminate the offer and process any bids to the offer that may bereceived from other parties that are then relayed to the offering partyby the transaction processor.

The exchanger server may control the electronic access of identifyinginformation of parties during an offer and bid process based on theparameters of confidentiality. The parameters of confidentiality mayinclude a specification or limitation of what information is keptprivate and criteria or conditions for allowing disclosure of theprivate information to an offer or bid. Prior to submitting a bid to theoffer, a potential bidding party may perform certain actions to satisfythe conditions under the parameters of confidentiality to be allowed todisclose private information associated with the offer and/or bid. Forexample, certain identifying information may be electronically blockedfrom being displayed at least until an agreement, such as aconfidentially agreement, has been executed or submitted by thepotential bidding party.

The server receives bids to the confidential offer from the exchangeserver, step 508. The exchange server may relay to the server one ormore bids that are responsive to the offer. The server may receive thebids as electronic messages, such as text messages and email, or via anapplication interface message from the exchange server. One or moreclient devices may access or connect with the server to review the bids.

The server determines whether a bid has been accepted for theconfidential offer, step 510. The server may continue to receive bids tothe confidential offer at step 508 until a bid has been accepted. Asignal may be received by the server that is representative of anacceptance of a given bid to the offer from the one or more clientdevices. If the acceptance signal is received by the server, anindication of acceptance of a given bid to the confidential offer istransmitted to the exchange server, step 512.

A transaction workflow is executed, step 514. A sales agreement may beentered with a buyer associated with the accepted bid in exchange forthe first policy in response to the indication of acceptance. Theexchange server may facilitate the sales agreement by generating atransaction workflow. The transaction workflow may include generatingforms or contracts and contacting relevant parties of a sale. The salesagreement may comprise the offering party associated with the serveragreeing to sell the first policy to the buyer in exchange for anagreement by the buyer to pay to the first insurance company thepremiums required to keep the first policy in force, pay certain fees tothe offering party and pay at least the value of the second policy tothe offering party upon the occurrence of an event, such as when theinsured of the policy dies. The issuer of the first policy may pay thevalue of the first policy to the buyer, the buyer pays or causes to bepaid at least the value of the second policy to the offering party, andthe offering party may then pay the value of the second policy to thebeneficiary of the second policy.

FIG. 6 presents a flowchart of a method for performing policy exchangeanalysis by a server and/or an analysis module according to anembodiment of the present invention. The server may secure confidentialinformation regarding potential investors, step 602. Potential investorsmay participate in purchasing assets generated by a policy exchangeprogram (“PEP”) by providing confidential information to the serverincluding income, amount of capital to invest, eligibility criteria andspecifics on recently acquired life insurance policy assets.

Relationships may be developed with investors to garner interest.Non-disclosure agreements may be signed with interested investors.Additionally, documents detailing an investor's directives may beobtained and used to determine the investor's eligibility criteria andcapacity. The server may also identify assets sold to investors. Adatabase of life insurance policy assets sold to investors may bereviewed. Data points and cash flows for each asset owned by theinvestors may be identified. An investor's expected return and riskappetite may be determined based on a combination of the confidentialinformation.

A database of key indicators for each investor is created by the serverbased on the confidential information, step 604, as described furtherwith reference to FIG. 7. Based on the key indicators, a risk appetitemay be determined for each investor, step 606. Formulas, as disclosedherewith, may be applied to calculate the risk appetite of eachinvestor. Additional details of determining risk appetite of eachinvestor is described further with reference to FIG. 8. Based on theformulas, the server may determine which of the potential investorswould be likely to purchase assets generated by the PEP, step 608, asdescribed further with reference to FIG. 9. A life insurance carrier isengaged to issue certificates for the PEP, step 610, as describedfurther with reference to FIG. 10.

Insured information related to life insurance policy assets that areeligible to participate in the PEP is obtained, step 612, as describedfurther with reference to FIG. 11. The specific information may includethe following data points:

#Life Insurance Policy Asset ID Number;

m Duration at which life insurance policy expires (measured from assetacquisition date);s Sex of insured;x Age of insured at policy issue date.

A range of premium payment cash flows is determined by retrieving lifeinsurance company premium illustrations, step 614. The server generatesa cashflow projection model that matches various expected cash flows tobe generated by the life insurance policy assets given its variousexpense and interest crediting components. The generated cashflowprojection model may utilize variables and formulas that are disclosedin further detail herewith. The generated projection model may be usedto determine cash flows required to support life insurance policy assetsunder various scenarios using formulas such as those set forth above.Determining a range of premium payment cash flows is described furtherwith reference to FIG. 13.

Additional expenses other than asset specific cash flows needed tocomplete a transaction under the PEP are built in, step 616. Alternativeoffers are negotiated based on the various combinations, step 618. Thealternative offers may be used in negotiating purchasing of eligiblelife insurance policy assets through the PEP.

FIG. 7 presents a flowchart of a method for creating a database of keyindicators for each investor according to an embodiment of the presentinvention. This method is performed during step 604 as set forth in FIG.6. The information gathered from step 602 is used to maintain a databaseof key information and indicators for each investor. A database isaccessed or created for the key indicators, step 702. The database maybe set up in structured query language (“SQL”) or any other programminglanguage compatible with databases, step 702. A main index is createdbased on investor and a sub-index is created based on investmentvehicle, step 704.

Database fields in the database are included with items that areidentified separately, step 706. Exemplary database fields may includenon-asset specific fields (e.g., name of investor, contact informationfor each key employee of investor, name, address/location, one or morecontact phone numbers, one or more contact email addresses, investmentvehicles, name of vehicle, jurisdiction, investment manager, investmentblend, investment strategy, investment directives, size, availablecapital to invest, location of source of funds (sub-investors), or riskappetite data) and asset specific fields (e.g., asset ID, purchaseprice, expected cash flows by duration, insured(s), name, age, sex,address, contact information, last time contacted, life expectancies(may be multiple), primary life expectancy (used to acquire asset), ormaturity indicator). Information regarding new assets is imported fromongoing review of data, step 708. Non-asset specific fields are updatedfrom ongoing review of data, step 710. Ongoing review of data maycomprise populating the database fields with information received fromdata import and/or entry from computing devices over a communicationsnetwork. A monthly activity report by investor is generated, step 712

FIG. 8 presents a flowchart of a method for determining risk appetite ofinvestors according to an embodiment of the present invention. Thismethod is performed during step 606 as set forth in FIG. 6. Formulas maybe applied to the key indicators from step 604 to determine the riskappetite of each investor. Asset specific data for each investor may beobtained. The database of life insurance assets sold to the investor isreviewed, step 802. Data points and cash flows for each asset areidentified, step 804.

An investor's expected return and risk appetite are determined, step806. Determining the investor's expected return and risk appetite mayinclude performing calculations, as disclosed in the following,periodically (and repeatedly) for each investor and for all assetspurchased by such investor. Data points for performing the calculationsmay include:

# Asset ID Number; I Investor; m Duration at which life insurance policyexpires (measured from asset acquisition date); n Scenario; s Sex ofinsured; t Duration (measured from asset acquisition date); x Age ofinsured at policy issue date; z Number of scenarios; LE Life expectancyestimate; MT Mortality Table used by investor to determine mortalitycurve; q_(x:t) Mortality rate for insured's sex, age of insured atpolicy issue date, duration since date in which the LE is determinedbased on mortality table MT; _(#)NDB_(t) Net Death Benefit payable ifdeath occurs in duration ‘t’ for asset #; _(#)CF_(t) Cash Flow forduration ‘t’ measured from date of asset acquisi- tion (as used by theinvestor in the valuation of the asset); and PP_(#) Purchase price paidfor asset ‘#’.

Variables for performing the calculations may include:

p_(x:t) Survival rate for insured's sex, age of insured at policy issuedate, duration since date in which the LE is determined based onmortality table MT;

tPx Probability of survival to end of duration ‘t’;

MR_(#) Mortality rating that causes the mortality curve to generate alife expectancy equal to LE;

MR_(s) Mortality rating that causes the mortality curve to generate alife expectancy equal to LE_(s) under a given scenario;

NPV_(n) Net present value of generated under scenario ‘n’;

#μ_(NPV) Average NPV;

#σ_(NPV) Standard Deviation of NPV; and

Iσ_(NPV-Max) Maximum observed standard deviation of NPV for investor“I”.

Formulas used in the calculations may include:

p _([x]+t) ^(s)=1−MR_(S) *q _([x]+t)

For each ‘t’,

${{tP}^{s}x} = {\prod\limits_{t = 0}^{m}p_{x + t}}$${NPV}_{\#} = {{\sum\limits_{t = 0}^{m}{{{}_{}^{}{}_{}^{}}*{tP}^{\#}x*{MR}_{\#}*q_{{\lbrack x\rbrack} + t}}} - {\sum\limits_{t = 0}^{m}{{tP}^{\#}x*{{}_{}^{}{}_{}^{}}}}}$${NPV}_{n} = {{\sum\limits_{t = 0}^{m}{{{}_{}^{}{}_{}^{}}*{tP}^{n}x*{MR}_{n}*q_{{\lbrack x\rbrack} + t}}} - {\sum\limits_{t = 0}^{m}{{tP}^{n}x*{{}_{}^{}{}_{}^{}}}}}$${{}_{}^{}{}_{}^{}} = {\frac{1}{z}*{\sum{NPV}_{s}}}$${{}_{}^{}{}_{}^{}} = \sqrt{\frac{\sum\left\lbrack {{NPV}_{s} - {{}_{}^{}{}_{}^{}}} \right\rbrack^{2}}{z}}$_(NPV − Max) = Max[]

FIG. 9 presents a flowchart of a method for determining likely investorsof a policy exchange program according to an embodiment of the presentinvention. This method is performed during step 608 as set forth in FIG.6. Based on the results from step 606, the disclosed computing systemdetermines which investors would be likely to purchase assets generatedby the PEP. Existing cases may be reviewed where residual death benefitswere put in place from the company's general portfolio of originatedassets and evaluate scenarios for each asset to determine expectedvolatility for the assets originated from PEP. These results may becompared with investors' eligibility criteria and risk appetite todetermine which investors could purchase the assets originated throughPEP.

Asset specific data for residual death benefit cases may be obtained. Adatabase of life insurance assets that have a residual death benefit isreviewed, step 902. Assets that participate in PEP are added to thedatabase, step 904. Data points and cash flows for each asset areidentified, step 906.

Expected return and volatility are determined for residual deathbenefit, death benefit, and PEP assets, step 908. The followingcalculations may be performed and repeated periodically for each asset.Data points for determining the expected return and volatility mayinclude:

# Asset ID Number; m Duration at which life insurance policy expires(measured from asset acquisition date); n Scenario; s Sex of insured; tDuration (measured from asset acquisition date); x Age of insured atpolicy issue date; z Number of scenarios; LE Life expectancy estimate;MT Mortality Table used to determine mortality curve; q_(x:t) Mortalityrate for insured's sex, age of insured at policy issue date, durationsince date in which the LE is determined based on mortality table MT;_(#)NDB_(t) Net Death Benefit payable if death occurs in duration ‘t’for asset #; _(#)CF_(t) Cash Flow for duration ‘t’ measured from date ofasset acquisi- tion (as used by the investor in the valuation of theasset); and PP_(#) Purchase price paid for asset ‘#’.

Variables for determining the expected return and volatility mayinclude:

p_(x:t) Survival rate for insured's sex, age of insured at policy issuedate, duration since date in which the LE is determined based onmortality table MT;

tPx Probability of survival to end of duration ‘t’;

MR_(#) Mortality rating that causes the mortality curve to generate alife expectancy equal to LE;

MR_(s) Mortality rating that causes the mortality curve to generate alife expectancy equal to LE_(s) under a given scenario;

NPV_(n) Net present value of generated under scenario ‘n’;

#μ_(NPV) Average NPV;

#σ_(NPV) Standard Deviation of NPV; and

μ_(NPV-σ) Maximum observed standard deviation of NPV.

Formulas used in the determination of the expected return and volatilitymay include:

p _([x]+t) ^(s)=1−MR_(S) *q _([x]+t)

For each ‘t’,

${{tP}^{s}x} = {\prod\limits_{t = 0}^{m}p_{x + t}}$${NPV}_{\#} = {{\sum\limits_{t = 0}^{m}{{{}_{}^{}{}_{}^{}}*{tP}^{\#}x*{MR}_{\#}*q_{{\lbrack x\rbrack} + t}}} - {\sum\limits_{t = 0}^{m}{{tP}^{\#}x*{{}_{}^{}{}_{}^{}}}}}$${NPV}_{s} = {{\sum\limits_{t = 0}^{m}{{{}_{}^{}{}_{}^{}}*{tP}^{s}x*{MR}_{s}*q_{{\lbrack x\rbrack} + t}}} - {\sum\limits_{t = 0}^{m}{{tP}^{s}x*{{}_{}^{}{}_{}^{}}}}}$${{}_{}^{}{}_{}^{}} = {\frac{1}{z}*{\sum{NPV}_{s}}}$${{}_{}^{}{}_{}^{}} = \sqrt{\frac{\sum\left\lbrack {{NPV}_{s} - {{}_{}^{}{}_{}^{}}} \right\rbrack^{2}}{z}}$μ_(NPV − σ) = Average []

Potential investors for PEP may be those whose eligibility criteria fitsthe requirements for PEP's assets and whose appetite for cash flowvolatility equals or exceeds the average standard deviation of an assetthat has a Residual Death Benefit or that participates in PEP:

I ^(σ) _(NPV-Max)≥μ_(NPV-σ)

FIG. 10 presents a flowchart of a method for engaging life insurancecarrier to issue certificates for a policy exchange program according toan embodiment of the present invention. This method is performed duringstep 610 as set forth in FIG. 6. Life insurance carriers that meet aminimum credit ranking requirement are identified, step 1002. Carrierswho are not U.S. tax payers are removed, step 1004. Carriers that canissue group life insurance are identified, step 1006. Carriers that arenot subject to non-compete, exclusive agreements are identified, step1008. Carriers that can mitigate mortality risk with an existing lifeinsurance policy are identified, step 1010. Carriers that have capacityto issue certificates as needed by PEP are identified, step 1012.Carriers who are willing to participate in PEP are identified, step1014.

A non-compete or exclusive agreement is signed and completed, step 1016.Contractual relationship and fee agreement between parties arenegotiated, step 1018. A product for PEP is developed, step 1020. Issueand administrative procedures are established, step 1022. Incrementalcash flows for PEP to use in pricing are identified, step 1024

FIG. 11 presents a flowchart of a method for obtaining information ofpolicy assets eligible for policy exchange according to an embodiment ofthe present invention. This method is performed during step 612 as setforth in FIG. 6. Leads of U.S. life insurance policy owners arereceived, step 1102. Ownership of life insurance policies that meetminimum size requirements is confirmed, step 1104. Answers to healthquestions are evaluated to determine potential qualification, step 1106.Policies that do not meet the health or policy size requirements areremoved, step 1108.

Authorization is obtained to obtain information from health serviceproviders related to the policies, step 1110. Medical records for eachapplicable health service provider are obtained, step 1112. Lifeexpectancy reports are generated based on the medical records and areassessed, step 1114. Policies that do not meet life expectancyrequirements are removed from consideration, step 1116

FIG. 12 presents a flowchart of a method for determining a range ofpremium payment cash flows according to an embodiment of the presentinvention. This method is performed during step 614 as set forth in FIG.6. Life insurance company premium illustrations may be secured todetermine the range of premium payment cashflows. Authorization is usedto obtain life insurance illustrations for each policy, step 1202.Policies that do not meet certain eligibility criteria are removed, step1204. The eligibility criteria may include policy type eligibilitycriteria, minimum size eligibility criteria, maturity date eligibilitycriteria, and policy duration eligibility criteria.

Non-lapse guarantees, policy shadow account provisions, minimum interestrate guarantees and other options available within the policy areidentified, step 1212. Current cash value, loans, options, and potentialpremium needs to prevent the policy from lapsing are evaluated, step1214. Policies that do not meet applicable eligibility criteria based onthe evaluation may be removed. Policies that do not meet minimum pricingrequirements are removed, step 1216. For each policy that remains after1216, a cash flow stream (premiums, loans and withdrawals) may bedetermined that may optimize the value of the asset (making sure thatthe cash flow levels in the period between acquisition and maturity donot cause the contract to lapse), step 1218. A cashflow projection modelmay be engineered to match various expected cash flows to be generatedby a life insurance policy asset given its various expense and interestcrediting components. The engineered projection model may be used todetermine cash flows required to support the life insurance policy assetunder various scenarios.

The following data points may be used in determining the cash flow:

m Duration at which life insurance policy expires (measured from assetacquisition date);

n Scenario;

s Sex of insured;

f In-force duration (measured from issue date to acquisition date);

t Duration (measured from asset acquisition date);

x Age of insured at policy issue date;

z Number of scenarios;

LE Life expectancy estimate;

MT Mortality Table used to determine mortality curve;

q_(x:t) Mortality rate for insured's sex, age of insured at policy issuedate, duration since date in which the LE is determined based onmortality table MT;

DB₀ Death benefit as of the acquisition date;

AV₀ Account value as of the acquisition date; and

CV₀ Cash surrender value as of the acquisition date.

The following variables may be used in determining the cash flow:

p_(x:t) Survival rate for insured's sex, age of insured at policy issuedate, duration since date in which the LE is determined based onmortality table MT;

tPx Probability of survival to end of duration ‘t’;

MR_(s) Mortality rating that causes the mortality curve to generate alife expectancy equal to LE_(s) under a given scenario;

L_(t) Loan balance at end of period ‘t’;

L₀ Loan balance outstanding as of the acquisition date;

LN_(t) Loan amount drawn at end of period ‘t’;

LR_(t) Loan repayment amount at beginning of period ‘t’;

i_(t) ^(l) Loan rate for period ‘t’;

c_(t) ^(l) Credited interest rate on non-loaned amounts for period ‘t’;

c_(t) ^(l) Credited interest rate on loaned amounts for period ‘t’;

DB_(t) Death benefit for duration ‘t’;

NDB_(t) Net Death Benefit payable if death occurs in duration ‘t’;

PDB_(t) Policy Exchange Program certificate death benefit for duration‘t’;

P_(t) Premium Payment at beginning of period ‘t’;

L_(t) ^(p) Premium load (as percentage of premium paid) for duration‘t’;

L_(t) ^(f) Policy load (as dollar amount adjusted for period duration)for duration ‘t’;

COIR_(t) Cost of insurance rate (as percentage of NDB) for duration ‘t’;

COI_(t) Cost of insurance charge for duration ‘t’;

W_(t) Cash withdrawal during period ‘t’;

AV_(t) Account Value at end of period ‘t’;

SC_(t) Surrender charge (as percentage of cash withdrawal amount) forduration ‘t’;

CF_(t) Cash Flow for duration ‘t’ measured from date of assetacquisition;

NPV_(n) Net present value of generated under scenario ‘n’;

PExp PEP program related expenses;

PR&C PEP Reserve and Capital Requirements; and

ChPRC Change from period to period of PR&C.

The following formulas may be used to determine the cash flow: For each‘t’ in any given scenario, from 1 to ‘m’

NDB_(t)=DB_(t) −CV _(t)

COI_(t)=COIR_(t)*NDB_(t-1)

L _(t) ^(B)=(L _(t-1) +LN _(t) −LR _(t))

L _(t) =L _(t) ^(B)*(1+i _(t) ^(l))

AV_(t)=(AV_(t-1) −L _(t) ^(B) −W _(t)+(1−L _(t) ^(P))*P _(t) −L _(t)^(F)−COI_(t))*(1+c)+L _(t) ^(B)*(1+c _(t) ^(l))

CV_(t)=AV_(t)−SC_(t)

CF_(t) =P _(t) +LN _(t) −LR _(t) −W _(t)

Scenarios may include (1) account value cannot be below zero at anytime, (2) cash surrender value cannot be below zero at any time, (3)shadow account, (4) minimum premium no-lapse guarantee, etc.

  p_([x] + t)^(s) = 1 − MR_(s) * q_([x] + t)$\mspace{20mu}{{{tP}^{s}x} = {\prod\limits_{t = 0}^{m}p_{x + t}}}$${NPV}_{n} = {{\sum\limits_{t = 0}^{m}{\left( {{{}_{}^{}{}_{}^{}} - {PDB}_{t} + {PRC}_{t}} \right)*{tP}^{n}x*{MR}_{n}*q_{{\lbrack x\rbrack} + t}}} - {\sum\limits_{t = 0}^{m}{{tP}^{n}x*\left( {{{}_{}^{}{}_{}^{}} + {PExp}_{t} + {ChPRC}} \right)_{t}}}}$

Cash flows for the scenario where the cash flows generate the greatestNPV_(n) may be selected.

FIGS. 1 through 12 are conceptual illustrations allowing for anexplanation of the present invention. Notably, the figures and examplesabove are not meant to limit the scope of the present invention to asingle embodiment, as other embodiments are possible by way ofinterchange of some or all of the described or illustrated elements.Moreover, where certain elements of the present invention can bepartially or fully implemented using known components, only thoseportions of such known components that are necessary for anunderstanding of the present invention are described, and detaileddescriptions of other portions of such known components are omitted soas not to obscure the invention. In the present specification, anembodiment showing a singular component should not necessarily belimited to other embodiments including a plurality of the samecomponent, and vice-versa, unless explicitly stated otherwise herein.Moreover, applicants do not intend for any term in the specification orclaims to be ascribed an uncommon or special meaning unless explicitlyset forth as such. Further, the present invention encompasses presentand future known equivalents to the known components referred to hereinby way of illustration.

It should be understood that various aspects of the embodiments of thepresent invention could be implemented in hardware, firmware, software,or combinations thereof. In such embodiments, the various componentsand/or steps would be implemented in hardware, firmware, and/or softwareto perform the functions of the present invention. That is, the samepiece of hardware, firmware, or module of software could perform one ormore of the illustrated blocks (e.g., components or steps). In softwareimplementations, computer software (e.g., programs or otherinstructions) and/or data is stored on a machine-readable medium as partof a computer program product and is loaded into a computer system orother device or machine via a removable storage drive, hard drive, orcommunications interface. Computer programs (also called computercontrol logic or computer-readable program code) are stored in a mainand/or secondary memory, and executed by one or more processors(controllers, or the like) to cause the one or more processors toperform the functions of the invention as described herein. In thisdocument, the terms “machine readable medium,” “computer-readablemedium,” “computer program medium,” and “computer usable medium” areused to generally refer to media such as a random access memory (RAM); aread only memory (ROM); a removable storage unit (e.g., a magnetic oroptical disc, flash memory device, or the like); a hard disk; or thelike.

The foregoing description of the specific embodiments will so fullyreveal the general nature of the invention that others can, by applyingknowledge within the skill of the relevant art(s) (including thecontents of the documents cited and incorporated by reference herein),readily modify and/or adapt for various applications such specificembodiments, without undue experimentation, without departing from thegeneral concept of the present invention. Such adaptations andmodifications are therefore intended to be within the meaning and rangeof equivalents of the disclosed embodiments, based on the teaching andguidance presented herein. It is to be understood that the phraseologyor terminology herein is for the purpose of description and not oflimitation, such that the terminology or phraseology of the presentspecification is to be interpreted by the skilled artisan in light ofthe teachings and guidance presented herein, in combination with theknowledge of one skilled in the relevant art(s).

What is claimed is:
 1. A system for processing electronic offers, thesystem comprising: at least one processing device; and at least onecomputer readable storage device storing data instructions that, whenexecuted by the at least one processing device, cause the at least oneprocessing device to: submit an electronic offer for a first policy thatis assigned from an owner of the first policy, the first policyincluding a first benefit value on a life of an insured and is issued bya first entity, the offer comprising data including an offer price forthe first policy and details regarding the first policy; receive a bidthat is responsive to the offer and an acceptance of the bid based on asignal from a client device via an application interface; and execute atransaction workflow including generating an agreement with a buyerassociated with the bid, the agreement comprising the buyer receivingthe first policy and (i) paying premiums to the first entity that keepthe first policy in force, (ii) paying certain fees to a second entity,which second entity issues to the owner at least one second policy witha second benefit value based on the life of the insured, the secondbenefit value comprising a portion of the first benefit value, and (iii)paying or causing to be paid to the second entity at least a secondbenefit value based on the life of the insured.
 2. The system of claim 1wherein the assignment is based on a transaction executed by the ownerof the first policy with the second entity.
 3. The system of claim 1wherein the processing device is further configured to electronicallyreceive the assignment via data entry or file attachment from acomputing device associated with the owner of the first policy.
 4. Thesystem of claim 1 wherein the processing device is further configured toissue the second policy as a paid-up certificate of insurance under agroup master policy.
 5. The system of claim 1 wherein the processingdevice is further configured to issue the second policy as an individualpaid-up life insurance policy.
 6. The system of claim 1 whereinprocessing device is further configured to issue the second policy tothe owner wherein the second policy includes a beneficiary that ischosen by the owner.
 7. The system of claim 1 wherein the processingdevice is further configured to issue the second policy to the ownerwherein the owner is not required to pay premiums to keep the secondpolicy in force.
 8. The system of claim 1 wherein the processing deviceis further configured to issue the second policy to the owner whereinthe first entity pays the first benefit value on the life of the insuredto the buyer, the buyer pays or causes to be paid at least the secondbenefit value on the life of the insured to the second entity, and thesecond entity pays the second benefit value on the life of the insuredto a beneficiary of the second policy.